Check disabled workflow when rerun jobs

[yp05327]

In GitHub, we can not rerun jobs if the workflow is disabled:

After:

[yp05327]

It seems that we have no global fetch post function, maybe we can reuse the code here as a global one.

gitea/web_src/js/features/common-global.js

Lines 119 to 161 in c6b92c8

	const onError = (msg) => {
	formEl.classList.remove('is-loading', 'small-loading-icon');
	if (errorTippy) errorTippy.destroy();
	// TODO: use a better toast UI instead of the tippy. If the form height is large, the tippy position is not good
	errorTippy = createTippy(formEl, {
	content: msg,
	interactive: true,
	showOnCreate: true,
	hideOnClick: true,
	role: 'alert',
	theme: 'form-fetch-error',
	trigger: 'manual',
	arrow: false,
	});
	};
	const doRequest = async () => {
	try {
	const resp = await fetch(reqUrl, reqOpt);
	if (resp.status === 200) {
	const {redirect} = await resp.json();
	formEl.classList.remove('dirty'); // remove the areYouSure check before reloading
	if (redirect) {
	doRedirect(redirect);
	} else {
	window.location.reload();
	}
	} else if (resp.status >= 400 && resp.status < 500) {
	const data = await resp.json();
	// the code was quite messy, sometimes the backend uses "err", sometimes it uses "error", and even "user_error"
	// but at the moment, as a new approach, we only use "errorMessage" here, backend can use JSONError() to respond.
	onError(data.errorMessage || `server error: ${resp.status}`);
	} else {
	onError(`server error: ${resp.status}`);
	}
	} catch (e) {
	console.error('error when doRequest', e);
	onError(i18n.network_error);
	}
	};
	// TODO: add "confirm" support like "link-action" in the future
	await doRequest();

[silverwind]

Yes, I would like to write some fetch wrapper functions eventually which automatically handles CSRF and maybe even redirects etc.

[wxiaoguang]

It seems that we have no global fetch post function, maybe we can reuse the code here as a global one.

Just improve the .link-action class event listener like .form-fetch-action

[silverwind]

Just improve the .link-action class event listener like .form-fetch-action

We need a generic fetch wrapper in any case.

[yp05327]

I tried to add a general fetch-action class and bind onClick event in common-global.js, but I got two problems:

• This page uses Vue, and functions in common-global.js will be called before the elements in Vue page loaded, so the class event listener will not work well to the elements in Vue pages.
• The rerun, approve, cancel buttons are controlled by variable. If I click cancel then the next disappeared rerun button will have no response, as event listener was removed and the new one have no event listener?

[wxiaoguang]

I tried to add a general fetch-action class and bind onClick event in common-global.js, but I got two problems:

I will try to improve it

[wxiaoguang]

Made some improvements to "link-action", you can test it on the page http:https://localhost:3000/devtest/fetch-action

I haven't tested the Vue code changes, feel free to ask if there is any problem.

[silverwind]

I know this is old code, but shouldn't we use 302 status code and then check resp.redirected and read location from resp.url? I think this is something for a future generic fetch handler.

[wxiaoguang]

Nope IMO.

Fetch's redirect could only have 3 behaviors: follow, error, manual.

follow is the default behavior, it doesn't distinguish 200/302, etc, error just stops redirection.

If you would like to use "redirect": "manual" .... IIRC it doesn't work well (the details are too complex)

You could take a try, if it would succeed, feel free to propose a new solution.

[silverwind]

Yes, that was implying manual option, but I guess it'll be hard to distinguish a "content redirect" from an "ui redirect", so I guess I'm fine with leaving it unchanged.

[silverwind]

@wxiaoguang could you port the Proxy implementation from #25940 here instead of extending this hack further? I think #25940 is not going to land anytime soon, so it's a good extract.

[wxiaoguang]

Hmm, I have different opinion. I think this "array" is a right approach. The reasons are:

1. The bug you met is not caused by the array, but by duplicate-init. I have added "inited" check in this PR, so you won't see any new problem.
2. Array is also widely used by big company products, for example, Google Analytics also uses ga.push(), the same method.
3. Using an object with "push" method is light than using a proxy object, and it doesn't need too much tricky code in the "set" method.

So, I would always prefer this approach.

[silverwind]

Does your hack even run in JS strict mode? Try adding "use strict"; to the file 😆.

[wxiaoguang]

It's not hack IMO, it strictly follows JS standard. And, why not run? I don't see any problem.

<script>
	window._testGlobal = [];
	window._testGlobal.push('foo');
</script>
<script src="{{AssetUrlPrefix}}/test.js"></script>

"use strict";

function test() {
  for (const e of window._testGlobal || []) {
    console.log(`test (pre): ${e}`);
  }
  window._testGlobal = {_inited: true, push: (e) => console.log(`test (after): ${e}`)};
}
test();

window._testGlobal.push('bar');

[silverwind]

I guess you are right and the problem I've been seeing may be because of that missing init. Still I personally prefer the Proxy method.

BTW, I would like our code to run in strict mode, but don't feel like littering every file with a "use strict". Maybe there are solutions for webpack to automatically inject it into every chunk like https://babeljs.io/docs/babel-plugin-transform-strict-mode.

[silverwind]

According to evanw/esbuild#422 (comment) we could use the esbuild banner feature for it.

[wxiaoguang]

Let's merge it and do more improvements in following PRs (if necessary)