Closed 0x4007 closed 2 months ago
One problem to solve though is that if a specific file was deleted from the template, for example, cypress related test code on a project that has no UI, I hope that this script will not attempt to re-add the deleted file.
If this problem is simple to solve then I think we should continue with this proposal. Otherwise it might make too much a mess with redundant changes.
I think that git is aware of a file that is deleted based on its timestamp, and will only add it back if the file was added (or modified?) in the ts-template
afterwards, so this should be a non-issue!
Instead of doing it as a CRON once a month, couldn't we do it on changes in the main branch? This way we wouldn't miss important updates, and I don't think we change this repo very often so it should not be noisy.
Instead of doing it as a CRON once a month, couldn't we do it on changes in the main branch? This way we wouldn't miss important updates, and I don't think we change this repo very often so it should not be noisy.
I don't understand what you mean by changes in the main branch, but the idea is that this CRON would exist in all of the repositories, and each would self sync.
/start
! Please set your wallet address with the /wallet command first and try again.
/wallet 0xB252053CE195115348199D0a6Ca9Eb97d5f0df83
+ Successfully registered wallet address
/start
Deadline | Tue, Aug 20, 10:18 PM UTC |
Registered Wallet | 0xB252053CE195115348199D0a6Ca9Eb97d5f0df83 |
<ul>
<li>Use <code>/wallet 0x0000...0000</code> if you want to update your registered payment wallet address.</li>
<li>Be sure to open a draft pull request as soon as possible to communicate updates on your progress.</li>
<li>Be sure to provide timely updates to us when requested, or you will be automatically unassigned from the task.</li>
<ul>
We might want to add this logic to https://github.com/ubiquibot/plugin-template afterwards.
View | Contribution | Count | Reward |
---|---|---|---|
Issue | Task | 1 | 300 |
Issue | Comment | 1 | 0 |
Review | Comment | 5 | 0 |
Comment | Formatting | Relevance | Reward |
---|---|---|---|
https://github.com/ubiquity/ts-template/pull/56 | 0content: p: symbols: \b\w+\b: count: 8 multiplier: 0 score: 1 multiplier: 0 | 0.1 | - |
Resolves #54 The script is located in .github/workflows/sync.y… | 0content: p: symbols: \b\w+\b: count: 60 multiplier: 0 score: 1 multiplier: 0 | 1 | - |
Okay, the sync.yml script now creates a pull request. Here is a… | 0content: p: symbols: \b\w+\b: count: 70 multiplier: 0.2 score: 1 multiplier: 0 | 1 | - |
I didn't manage to get the script that adds it to every repo wor… | 0content: p: symbols: \b\w+\b: count: 34 multiplier: 0.2 score: 1 pre: symbols: \b\w+\b: count: 260 multiplier: 0.2 score: 0 code: symbols: \b\w+\b: count: 260 multiplier: 0.2 score: 1 multiplier: 0 | 1 | - |
Okay, I think it works now. | 0content: p: symbols: \b\w+\b: count: 6 multiplier: 0.2 score: 1 multiplier: 0 | 1 | - |
Done. | 0content: p: symbols: \b\w+\b: count: 1 multiplier: 0.2 score: 1 multiplier: 0 | 1 | - |
View | Contribution | Count | Reward |
---|---|---|---|
Issue | Specification | 1 | 28.5 |
Issue | Comment | 2 | 7.72 |
Review | Comment | 5 | 11 |
Comment | Formatting | Relevance | Reward |
---|---|---|---|
It could be interesting to bake in a CRON job that runs once a m… | 28.5content: p: symbols: \b\w+\b: count: 90 multiplier: 0.1 score: 1 code: symbols: \b\w+\b: count: 1 multiplier: 0.1 score: 5 multiplier: 3 | 1 | 28.5 |
I think that git is aware of a file that is deleted based on its… | 8.6content: p: symbols: \b\w+\b: count: 41 multiplier: 0.2 score: 1 code: symbols: \b\w+\b: count: 2 multiplier: 0.2 score: 1 multiplier: 1 | 0.6 | 5.16 |
I don't understand what you mean by changes in the main branch, … | 6.4content: p: symbols: \b\w+\b: count: 32 multiplier: 0.2 score: 1 multiplier: 1 | 0.4 | 2.56 |
```suggestion - cron: '14 0 1 * *' `` … | 1.6content: pre: symbols: \b\w+\b: count: 4 multiplier: 0.1 score: 0 code: symbols: \b\w+\b: count: 4 multiplier: 0.1 score: 1 p: symbols: \b\w+\b: count: 12 multiplier: 0.1 score: 1 multiplier: 1 | 1 | 1.6 |
Can you show your test branch results? Once you proved this work… | 3.2content: p: symbols: \b\w+\b: count: 32 multiplier: 0.1 score: 1 multiplier: 1 | 1 | 3.2 |
Can you get it to auth as our bot like in our other ci | 1.4content: p: symbols: \b\w+\b: count: 14 multiplier: 0.1 score: 1 multiplier: 1 | 1 | 1.4 |
Every repo has our credentials stored. It's an org secret. | 1.1content: p: symbols: \b\w+\b: count: 11 multiplier: 0.1 score: 1 multiplier: 1 | 1 | 1.1 |
Before accepting this pull and paying out the reward, please ope… | 3.7content: p: symbols: \b\w+\b: count: 37 multiplier: 0.1 score: 1 multiplier: 1 | 1 | 3.7 |
View | Contribution | Count | Reward |
---|---|---|---|
Issue | Comment | 2 | 4.66 |
Review | Comment | 6 | 19.4 |
Comment | Formatting | Relevance | Reward |
---|---|---|---|
Instead of doing it as a CRON once a month, couldn't we do it on… | 4.6content: p: symbols: \b\w+\b: count: 46 multiplier: 0.1 score: 1 multiplier: 1 | 0.85 | 3.91 |
We might want to add this logic to https://github.com/ubiquibot/… | 1.5content: p: symbols: \b\w+\b: count: 15 multiplier: 0.1 score: 1 multiplier: 1 | 0.5 | 0.75 |
Could we rename this to `sync-template.yml` for clarity? | 1.3content: p: symbols: \b\w+\b: count: 10 multiplier: 0.1 score: 1 code: symbols: \b\w+\b: count: 3 multiplier: 0.1 score: 1 multiplier: 1 | 1 | 1.3 |
```suggestion git commit -m "chore: sync … | 0.6content: pre: symbols: \b\w+\b: count: 6 multiplier: 0.1 score: 0 code: symbols: \b\w+\b: count: 6 multiplier: 0.1 score: 1 multiplier: 1 | 1 | 0.6 |
Doesn't this directly merge in the content instead of opening a … | 5.2content: p: symbols: \b\w+\b: count: 52 multiplier: 0.1 score: 1 multiplier: 1 | 1 | 5.2 |
@zyrafal I tried on my own org, and it seems to crash if there a… | 3.3content: p: symbols: \b\w+\b: count: 31 multiplier: 0.1 score: 1 a: symbols: \b\w+\b: count: 2 multiplier: 0.1 score: 1 multiplier: 1 | 1 | 3.3 |
The workflow seemed to work: https://github.com/Meniole/command-… | 5.7content: p: symbols: \b\w+\b: count: 57 multiplier: 0.1 score: 1 multiplier: 1 | 1 | 5.7 |
This requires every repo to have our credentials stored because … | 3.3content: p: symbols: \b\w+\b: count: 33 multiplier: 0.1 score: 1 multiplier: 1 | 1 | 3.3 |
@0x4007 Why does it say "execution reverted" when I try to claim it? Do I need funds on the account to cover a fee or something?
Yes you need to pay the gas fee
@0x4007 Ummmm... Could you just send me the 0.0002 XDAI I need for the fee? I'm having trouble finding a way to transfer any funds there. I'll send it back as soon as I get my funds if it matters. Edit: nevermind I figured it out.
@zyrafal I'm not sure if this was resolved for you or not but this faucet will give you enough for a few transactions
Please see this issue https://github.com/ubiquity/pay.ubq.fi/issues/295. There are a lot of default things I'd have excluded from the start by default as all of these workflow installs are going to need manually customized to ignore the same things each month, or we repeat the same merge handling each month for these aspects in all repos essentially. It appears we cannot exclude via dir but it needs to be a filename and ext
/tests
/static
/build
/cypress
Could it be possible to ignore dependencies from being pulled in too, as we'll be having to handle that each month too with some repos not having a jest suite for example.
and any conflicts would be expected to be manually resolved.
I read this line just to make it clear I have read the convo this morning lol but if this happens every month forever surely we can optimize it further
The way git works means if you removed it once it won't come in again, unless it was re-added again afterwards in the ts-template. I verified that behavior before approving the sync script task.
https://github.com/ubq-testing/pay.ubq.fi/commit/70318ddd86950e2d4a638ea4716e67cac98b8fdf
So if I handle this first sync PR and delete everything that I do not want merged, then the next time it runs so the 2nd PR, there won't be any of the things that I had to delete from the first PR? Is that what you mean because that's pretty cool if that works
That is how git is supposed to work.
The way git works means if you removed it once it won't come in again, unless it was re-added again afterwards in the ts-template. I verified that behavior before approving the sync script task.
I don't understand how this would work. Every time this workflow runs ubiquity/ts-template
is cloned and then every file is copied from the template over to the repo and then pushed. git add .
is used so it will add all files even new ones, unless we used git add -u .
but then any new files in the template repo won't be added to the PR.
Currently trying to test it but I can't get it working: https://github.com/ubiquity-whilefoo/test/actions/runs/10774969004/job/29878307659
I tested it before finalizing the spec. It is possible in the scenario that I tested it might not include some type of edge case.
I did some research with ChatGPT to also verify my results.
Are we thinking of a same situation? For example:
ts-template
cypress
folder because I don't need itcypress
folderIn this situation the workflow did create cypress
folder which you can see from my run above.
EDIT: ChatGPT confirmed it: https://chatgpt.com/share/fb763d6a-5bd7-46ff-8aa3-f57befdd6873
Then I must be remembering something wrong. As I understand:
A = template
The comment you wrote about git add might be the solution.
The sync template workflow simply adds a mess to a repository and waste of development time.
This approach doesn't work for complex repositories because the amount of time spent for fixing merge conflicts, failing builds and broken features for such PRs is greater compared to manual adding of the missing ts-template
features (like linters or whatever).
If some repo really need a sync with ts-template
(What are real use cases by the way? Except for linters or knip workflows.) then in the end it must be done manually. Syncing the whole zoo of our repositories with ts-template
on a daily basis is a hell.
We'd better delete the sync template workflow from all of our repos.
It's supposed to be once a month and if it's a problem then the pull can be closed. I think it's worth a try because in my (limited) testing it was fine.
We'd better delete the sync template workflow from all of our repos.
Working on it!
It could be interesting to bake in a CRON job that runs once a month to attempt to sync the template.
This will ensure that our repositories in the future are effortlessly synced.
A pull request can be opened up against the
development
branch, and any conflicts would be expected to be manually resolved.Add this to our active repositories as well. I suppose a script could be made to add the action file to all of our active repositories. "Active" can be defined as updated within the last month.