js-org / js.org-cleanup Goto Github PK

When iterating through the diff in the validate command, if we encounter an added part immediately after a removed part, we report this as an expected/found diff:

Due to this, when we encounter a removed part with the immediate next part being an added part, we should not report the removal. This bug can be seen in this run: https://github.com/js-org/js.org/runs/5720998192?check_suite_focus=true

Whilst every method in the script has a correct JSDoc descriptor attached, this should really have an overall README which describes the three index.js flags and what they do, alongside covering the config JSON file.

I somehow forgot to build this repo from my GitHub template repo.
We should bring in the files from https://github.com/MattIPv4/template, please.
The README can be very simple and plain, with the description of the repo only, until #1 is completed.

js-org/js.org#8873 (comment)

When the main pr process is called and the final pull request for the cleanup is created, the main cleanup issue should be locked to avoid any users commenting on this once the pull request has been made.

It may also be appropriate to post a comment in the issue informing maintainers that the cleanup is complete and no further changes need to be made to the issue as the pull request has been opened.

The pull request template should include a keyword to close the issue once merged. Eg Closes #xxx.

https://github.com/js-org/js.org/pull/8480 migrated all netlify.com usage to netlify.app, and as such we should update the CNAME parsing logic in validation/cleanup to automatically map netlify.com subdomains to netlify.app, similar to how we map Vercel subdomains.

This should be a minor thing to complete, but it would be much cleaner if the script files were all located within a subfolder such as src, with only index.js being located at the root of the project.

Add support for entries having a // cleanup-ignore comment on them, which will allow them to skip the validation process for cleanup.

This will also involve a minor change to the validate logic for detecting/formatting the file, to allow // cleanup-ignore or // noCF cleanup-ignore.

See js-org/js.org@5ecb09a / https://github.com/js-org/js.org/runs/5806385291?check_suite_focus=true

Line number for addition in diff is incorrect

If an entry in cnames_active.js requests a target that is the same as the subdomain being requested (e.g. "test": "test.js.org"), we should have an error.

In a recent CI run, it was observed that the validate script output an error message stating it could not find the var declaration in the cnames_active.js, but this did not cause the CI run to fail.

https://github.com/js-org/js.org/runs/8112104112?check_suite_focus=true

If an entry was present in the cnames_active.js file such as "test.js.org": "test.com", we should have an error for js.org being included in the key as a suffix.

When an entry is encountered in cnames_active.js that is for a sub-sub-domain (or deeper) (e.g. "test.test": "test.com"), require that the // noCF flag is present for the entry.