search

ivan-hc / AM

AppImage package manager to install, update (for real) and manage ALL of them (system-wide or locally) thanks to its ever-growing AUR-inspired database listing 2000+ portable apps and programs for GNU/Linux. The first, real centralized repository to manage your AppImages with the ease of APT and the power of PacMan.
https://portable-linux-apps.github.io
GNU General Public License v3.0
458 stars 32 forks source link

am -u/U should "update" AM-Updater with $HeaderAuthWithGITPAT for installed AppImages #192

Closed nazdridoy closed 7 months ago

nazdridoy commented 7 months ago

Description: Title should suffice

Ref: ./modules/update.am


for f in $APPSPATH/*/; do 
    cd $f 2>/dev/null && 
    if test -f ./AM-updater; then
        ########## check for ghapikey.txt and add  HeaderAuthWithGITPAT before running ##########
        ########## AM-updater (version checking depends on git_pat )                   ##########
        start=$(date +%s); $(sh -x ./AM-updater > /dev/null 2>&1) | echo -ne ' Updating "'$(printf '%s\n' "${PWD##*/}")'"...\r'; end=$(date +%s)
        echo -e " ◆ $(echo $(printf '%s\n' "${PWD##*/}") | tr a-z A-Z) is updated, $(($end-$start)) seconds elapsed!"
    else
        echo ""  > /dev/null 2>&1
    fi
done

@ivan-hc If you could look into this, that would be great. Otherwise, I'll work on it next Friday.

ivan-hc commented 7 months ago

Yes, this shouldn't change anything. Ultimately you intend to insert a function to identify URLs pointing to api.github.com in the AM-updater scripts (if they point to that site) and patch them with the API key on the fly. Is it right?

nazdridoy commented 7 months ago

patch them with the API key on the fly. Is it right?

yes, unless you have changed install.am. this is how we are handling ghApi.

nazdridoy commented 7 months ago

this shouldn't change anything.

it should. if you change your api key or install AppImages before setting git_pat. you will have issue.

ivan-hc commented 7 months ago

yes, unless you have changed install.am. this is how we are handling ghApi.

your line its still there

https://github.com/ivan-hc/AM/blob/2fea4d8d81be2ff1ae24528a12b35a0fdd3b7ff0/modules/install.am#L98

this shouldn't change anything.

it should. if you change your api key or install AppImages before setting git_pat. you will have issue.

I've never had problems, nor I needed APIkey... your idea is good... but I woud be careful when changing codes. Today I have restored the about.am module to the original form (before version 6), see https://github.com/ivan-hc/AM/commit/4c0e4674b79771447d70339dec2c4bebba86e853

ivan-hc commented 7 months ago

I've never had problems, nor I needed APIkey... your idea is good... but I woud be careful when changing codes. Today I have restored the about.am module to the original form (before version 6), see https://github.com/ivan-hc/AM/commit/4c0e4674b79771447d70339dec2c4bebba86e853

in brief:

You have to excuse me, it was also my fault, for I hadn't carefully checked your PR at the time.

Now everything is solved. But I would like you to avoid tampering with these modules too much. I know you do this with good intentions, not because you want to create flaws in the processes.

nazdridoy commented 7 months ago

restored the about.am module to the original form (before version 6),

reverting without finding the core issue is probably not a good idea. you could have created an issue and let us at least check whats the issue.

nazdridoy commented 7 months ago

I've never had problems, nor I needed APIkey... your idea is good... but I woud be careful when changing codes. Today I have restored the about.am module to the original form (before version 6), see 4c0e467

in brief:

  • the first time I noticed, during the installation of the apps, that during the installation process I received an error message relating to the impossibility of removing the ./cache/about directory... I responded by adding to "install.am" the complete removal of the elements in the cache, just so as not to tamper with the module you worked on, you are in good faith, so I overlooked what happened;
  • today I received messages in "about" that were double, triple, quadruple... this is because the old ones were not deleted. I then decided to restore everything to its original form, since, before your intervention, everything was working correctly.

You have to excuse me, it was also my fault, for I hadn't carefully checked your PR at the time.

Now everything is solved. But I would like you to avoid tampering with these modules too much. I know you do this with good intentions, not because you want to create flaws in the processes.

well you still haven't cleared what was the actual issue. off course reverting to a previous version solves new issue. if you just revert without addressing the actual issue progress will stagnant. modularization was a huge change. so it can definetly introduce new bug. we should address new bugs, not revert to old version.

again, i don't understand how about.am could cause such issue. if it did, most probably it was not the only issue rather it could a symptom of a larger issue, that is why i and many others have proposed refactoring.

ivan-hc commented 7 months ago

reverting without finding the core issue is probably not a good idea. you could have created an issue and let us at least check whats the issue.

That's the problem, we have different coding styles. I had to make a change to display the pages so as not to fill the terminal window with too many empty spaces (for example, deleting 4 screenshots from the Markdown file). This very difference in our styles brought me confusion. But as I told you, I had found problems before, and avoided editing your work. I know how "AM" works, and if I added all those lines that may appear "confusing" to the eyes of a professional developer like you, it's because I knew what I wanted to see in the terminal, and it wasn't those errors I saw.

However, nothing happened. The important thing is that everything works as before, and better (i.e. according to my vision of how the function should appear to the end user, during its execution).

Don't take it the wrong way. I have also submitted PRs in other projects, and they were initially rejected because my style did not follow that of the developer. In the end it is always the creator who decides. If one day you were to create your own project, and I wanted to send you a PR, I will certainly have to follow your style, or suggest the modification, and you, as an expert, could correct or distort it, knowing what that function does.

I am wrong?

ivan-hc commented 7 months ago

@nazdridoy

well you still haven't cleared what was the actual issue

I've already given an answer

  • the first time I noticed, during the installation of the apps, that during the installation process I received an error message relating to the impossibility of removing the ./cache/about directory... I responded by adding to "install.am" the complete removal of the elements in the cache, just so as not to tamper with the module you worked on, you are in good faith, so I overlooked what happened;
    • today I received messages in "about" that were double, triple, quadruple... this is because the old ones were not deleted. I then decided to restore everything to its original form, since, before your intervention, everything was working correctly.

now...

off course reverting to a previous version solves new issue. if you just revert without addressing the actual issue progress will stagnant.

"AM" have never had problems before the refactoring. I see the refactoring as just a way to "beautifize" the code, it's not a way to make it work the way the ignorant developer who created it intended (me).

modularization was a huge change

I agree

so it can definetly introduce new bug

I don't like this thing

we should address new bugs, not revert to old version

if you throw a glass plate on the ground, we already know that it will break, there is no need to test it... also because if you glue it afterwards, it is possible that, while eating, you will ingest glass flakes

again, i don't understand how about.am could cause such issue. if it did, most probably it was not the only issue rather it could a symptom of a larger issue, that is why i and many others have proposed refactoring.

the problem here is the style of the code. I don't want to make it "beautiful", I want to make it "useful", even at the cost of writing "shit". A well-known Italian singer-songwriter, Fabrizio De André, said, "nothing is born from diamonds, flowers are born from manure". Do you like using "AM"? If so, it's because I wrote it that way, to make it work the way you like it. If you then have to see the ugly code inside, you lose all the pleasure of using it. Why do you eat fruit and vegetables? Because it's good! Yet plants grow by eating shit. But you don't think about it, and you eat anyway.

nazdridoy commented 7 months ago

@ivan-hc its not about being an expert or not. tbh, i don't think i'm an expert, far from it.

I know how "AM" works, and if I added all those lines that may appear "confusing" to the eyes of a professional developer like you, it's because I knew what I wanted to see in the terminal, and it wasn't those errors I saw.

that is why you, @zen0bit and i had our last conversation. you have to decide if you you want others to know what you know about AM. cause we genuinely don't. it okay to implement things in your own way. but if you want others to contribute you have to open up about you ideas. or be a bit more patient. rather than merging any PR you can rigorusly test the PR and see if it satisfy your "internal" standers.( that how most closed Source and some OOS make changes to their codebase. ) if the PR seems ok and you commit it the main brunch, later notice a bug that may not directly originated from that PR rather from other part of the codebase, you can create new issue to find the root cause of the bug and fix those. I don;t believe in accepting PR in good faith or reverting without finding the root cause its counter productive.

ivan-hc commented 7 months ago

@nazdridoy I really think that you are a good developer and expert of shell scripting, more than me. But as you said, you are learning. I'm learning too. However, despite being an amateur, I got carried away, and ended up opening too many projects, and I have to respond to all of them to try to make them work. This is why I have decided not to publish new AppImages anymore.

"AM"/AppMan are now one thing, luckily... but I also have ArchImage, GIMP, VLC, OBS Studio, MPV... now also Bottles... too many projects for just one amateur who signed up to github just "for fun". More than having fun, I'm getting stressed. And seeing my main project, "AM", have problems that didn't exist before the refactoring... makes me even more exhausted. Not to mention that I stay up whole nights trying to solve these problems, as well as the ones I have in real life that I won't list here.

I understand the enthusiasm of wanting to contribute to a project that you consider valid. I thank you. I am honored by this. But try to understand my situation. I would like to avoid as much as possible the problems that arise with these experiments, because refactoring is experimentation, school. If I can, I would like to avoid the bugs of the new and rely on the certainties of the old. This project has been in existence for three years. Three.

nazdridoy commented 7 months ago

"AM" have never had problems before the refactoring. I see the refactoring as just a way to "beautifize" the code, it's not a way to make it work the way the ignorant developer who created it intended (me).

i can't really give you any rational reply if are going to take things personally. refactoring was not to "beautifize". it is to lessen the issue you face with other peoples PRs. noone can understand how you think or feel looking at your code. they can only try to interprete the rational behind each line.

if you throw a glass plate on the ground, we already know that it will break, there is no need to test it... also because if you glue it afterwards, it is possible that, while eating, you will ingest glass flakes

dude its 2024; software breaks

@ivan-hc no matter what you say if you think and act that way it will be extremely difficult (unless they can read mind) for other to work on this project. i can respect if you want to work on your own that fine, but you can't expect others to contribute but act like its your personal project.

nazdridoy commented 7 months ago

@nazdridoy I really think that you are a good developer and expert of shell scripting, more than me. But as you said, you are learning. I'm learning too. However, despite being an amateur, I got carried away, and ended up opening too many projects, and I have to respond to all of them to try to make them work. This is why I have decided not to publish new AppImages anymore.

"AM"/AppMan are now one thing, luckily... but I also have ArchImage, GIMP, VLC, OBS Studio, MPV... now also Bottles... too many projects for just one amateur who signed up to github just "for fun". More than having fun, I'm getting stressed. And seeing my main project, "AM", have problems that didn't exist before the refactoring... makes me even more exhausted. Not to mention that I stay up whole nights trying to solve these problems, as well as the ones I have in real life that I won't list here.

I understand the enthusiasm of wanting to contribute to a project that you consider valid. I thank you. I am honored by this. But try to understand my situation. I would like to avoid as much as possible the problems that arise with these experiments, because refactoring is experimentation, school. If I can, I would like to avoid the bugs of the new and rely on the certainties of the old. This project has been in existence for three years. Three.

its ok man. if you don't want AM to be modularized. you can revert to pre-version:6. huge respect for your effort!

ivan-hc commented 7 months ago

i can respect if you want to work on your own that fine

that's not what I said, I'm happy when you add new apps to the database. This is not working alone, but working together. See how I've been working on the template.am module lately. Try using it now, and let me know.

but you can't expect others to contribute but act like its your personal project.

@nazdridoy "AM" was born as my personal project, the options were also born because you asked me, including you. Who suggested I enter "apikey"? You. And --launcher? --rollback? firejail? newrepo? All suggestions of the users.

So, tell me, who is working for others now?

its ok man. if you don't want AM to be modularized. you can revert to pre-version:6. huge respect for your effort!

also modulization was your own idea, I liked it, and I did it. So don't say I want to do everything on my own. If I improved this project it is thanks to you. Don't make me look like the tyrant I'm not. I do not deserve it.

ivan-hc commented 7 months ago

And now, @nazdridoy , why have you closed this issue? Do you give up so early? I'm interested in what you have to tell me.

zen0bit commented 7 months ago

| "AM"/AppMan are now one thing, luckily... but I also have ArchImage, GIMP, VLC, OBS Studio, MPV... now also Bottles... too many projects for just one amateur who signed up to github just "for fun". More than having fun, I'm getting stressed. And seeing my main project, "AM", have problems that didn't exist before the refactoring... makes me even more exhausted. Not to mention that I stay up whole nights trying to solve these problems, as well as the ones I have in real life that I won't list here.

That Linting thing again...

We wanna help you, but we must learn your script first (your bash style is language barrier like wall, we must climb prior to help you with any coding...)

So you can live your life and your project grow even without your constant updates. You must do it!

Not because I said that. Because same will tell you anyone bit experienced with interest of participating

Sooner or later...

So here is simple choice.

  1. Code everything on your own
  2. Comply with linting so anyone can help you, so you can do more important things and project will no suffer...

PS: I am also thinking, after adding AM to neofetch, add it to repology.org which could lead to more eyes on AM and AppImages in general. (But not messed with python)

ivan-hc commented 7 months ago

I think I'll start learning the about.am module of @nazdridoy and then apply the fixes right there

ivan-hc commented 7 months ago

https://github.com/ivan-hc/AM/pull/193

nazdridoy commented 7 months ago

thanks @zen0bit , thats what i was trying to say

@ivan-hc It's not about design philosophy or programming style. If it were Java, Python, Rust, or JavaScript, we could argue about the programming paradigm. But we're writing Bash for goodness' sake.

Yes, it's true, you may have a certain way of expressing things. For example:

echo '####test####'
four_pound="####"

echo "${four_pound}test${four_pound}"

Let me tell you again, I'm working on this tool because I like AppImage and this tool. I want it to succeed. I would have forked it with my own changes, but that doesn't contribute to the community, and I want a net positive impact. I love AppImage, but I kind of hate the AppImage community, as from its creator to almost every significant member of this community care more about emotional drama and less about actually making something to keep the very same community alive.

In the end, I have huge respect for you for taking the initiative and unlike many others (including me) ditching AppImages. But I'm kind of disappointed in how you handle contributions. I have no doubt you want AM to succeed and have greater adoption, but I'd hate to see people (mainly developers who want to really help you improve AM) leave this project or ignore it altogether, or worse, fork it and disown its creator. I respect probonopd, but please don't be like him. It will actively harm the AppImage community.

If you wish to receive contributions to this project, please write a simple CONTRIBUTION.md and consider the above-mentioned suggestions to solve future issues. Until then, I'll respect your decision and not make any changes to AM or make PRs, and I'll discourage others from making any PRs and give you some time to think and chalk out a guideline.

ivan-hc commented 7 months ago

@nazdridoy I repeat, I'm sorry for how I behaved. The truth is that I have no experience with working in teams, let alone on github. There is always more to learn and even this time I had to fall to learn not to do it again. I got a little too carried away by the tension of the last few hours, both with regards to the projects I have on github and with other things, outside of github, in real life.

Be patient, please. I would like to go back and avoid doing what I did. From now on I will try to deal with situations calmly.

I started this project to save AppImage, since the authors don't care about it as they should... and I was making the same mistakes without realizing it. Thanks for pointing that out to me. I won't make the same mistakes again.

nazdridoy commented 7 months ago

@ivan-hc , I do appreciate that you understand the situation, and I also understand where you are coming from. It's natural to panic when seeing a relatively stable production software throwing random errors; no one wants confused end-users with random bugs.

That is the exact thing that we are trying to solve.

To preserve your and everyone else's sanity, 'am --upstream [branch-name]' is the ideal solution. User experience should not be affected. Developers can choose feature branches to test and develop whereas end users, by default, pull from the 'production' branch. It is not very difficult to implement since you are using api.github.com anyway.

However, I personally can't feel at ease until and unless you write a CONTRIBUTING.md. Please write a basic one with some general guidelines (like only push to dev branch, not production, and how one should set upstream branch as 'main' to test their changes and every push to dev to main may take less time but from main to production will take 2 weeks for testing, and so on). use this as a reference It is absolutely necessary since AM, in its current state, is very fragile for development and sensitive to changes.

https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors

p.s: If you are having a rough time IRL, take a break and then come back with a fresh mind. After you write the CONTRIBUTING.md, please mention me. I'm reopening this issue.

ivan-hc commented 7 months ago

You've listed a lot of things, and I find it all very complicated. Could you fill out such a form yourself?

I wouldn't even know where to start to create something like this.

If you are having a rough time IRL, take a break and then come back with a fresh mind

impossible, I can't explain right now. In fact, staying here helps me not to think about it.

ivan-hc commented 7 months ago

@nazdridoy @zen0bit have you got discord or reddit?

zen0bit commented 7 months ago

both but what about jabber, irc, lemmy, simplex instead? Simply something open source?

ivan-hc commented 7 months ago

because I have only Discord and Reddit, and I shouldn't have social networks

nazdridoy commented 7 months ago

You've listed a lot of things, and I find it all very complicated. Could you fill out such a form yourself?

Just write a basic one with simple guidelines. Then I can definitely help you improve it.

this one looks simpler

@nazdridoy @zen0bit have you got discord or reddit?

yeah i use discord.

zen0bit commented 7 months ago

create discord group for AppImages (AM) and share link

ivan-hc commented 7 months ago

Just write a basic one with simple guidelines. Then I can definitely help you improve it.

this one looks simpler

@nazdridoy Do you want to create it yourself? You are more practical. Besides, the idea is yours. I don't know what to do other than to upload the apps into the database.

create discord group for AppImages (AM) and share link

@zen0bit Do you want to create this group? I'm not familiar with Discord, I only signed up to talk privately with the Bottles developer (he asked me to). You can share the link later for the invitation, I'm ivan-hc (if you see a metalhead, its me)

nazdridoy commented 7 months ago

Do you want to create it yourself? You are more practical. Besides, the idea is yours. I don't know what to do other than to upload the apps into the database.

I'll definitely help you, but the initial guidelines should be written by you. Don't worry about formatting or conventions. Just describe what you expect from those who want to contribute to AM with some bullet points. It's kind of like a README.md but only shown when one tries to create a new PR.

To help your project contributors do good work, you can add a file with contribution guidelines to your project repository's root, docs, or .github folder. When someone opens a pull request or creates an issue, they will see a link to that file. The link to the contributing guidelines also appears on your repository's contribute page. For an example of a contribute page, see github/docs/contribute. ref

You don't have to write it right away. Take your time. I'll modify it later after discussing with you.

nazdridoy commented 7 months ago

with the Bottles developer (he asked me to)

mirkobrombin? Great guy, but he suffered a lot with third-party package maintainers of Bottle. What did he say? Is he okay with your package?

ivan-hc commented 7 months ago

Mirko? Him has apreciated that I was working on the package, and him is happy because I made it work.

However, I've already said to him that my package is not a conventional one, being it built on top of Debian Stable (too new for Probonopd) with some libraries built from Arch.... however, it workf with GLIBC versions equal or higer to the one of Debian Stable.

Mirko is italian, like me :)

ivan-hc commented 7 months ago

For him its ok that I distribute it as a third party package, since it works.

zen0bit commented 7 months ago

@zen0bit Do you want to create this group? I'm not familiar with Discord, I only signed up to talk privately with the Bottles developer (he asked me to). You can share the link later for the invitation, I'm ivan-hc (if you see a metalhead, its me)

Don't wanna create new one, but already have one for distrohopper so we can use that one.. dh discrord group

ivan-hc commented 7 months ago

I'm in

nazdridoy commented 7 months ago

For him its ok that I distribute it as a third party package, since it works.

oh, great. I haven't tried the AppImage yet. I'm using the AUR one after dealing with Flatpak's permission nightmare.

we can use that one..

sure

ivan-hc commented 7 months ago

@nazdridoy you were partially right, while I was partially wrong: is update.am the module to modify for this issue.

What to do?

While the module is executing:

ivan-hc commented 7 months ago

this is because none cares about the AM-updater script other than update (and rollback, but if you use the latter is because what update has done was not you were looking for, i.e. the program updated to the last version is broken)

ivan-hc commented 7 months ago

@nazdridoy for example

if grep -q "github_pat_" $APPSPATH/$2/AM-updater; then
    ghapikey=$(echo "Authorization: token  $(cat $APPSPATH/$2/AM-updater | tr ' ' '\n' | grep "github_pat")")
    if [ "$ghapikey" != "$HeaderAuthWithGITPAT" ]; then
            sed -i "s/$ghapikey/$HeaderAuthWithGITPAT/g" $APPSPATH/$2/AM-updater
    fi
fi

in this case, we assume that the "$HeaderAuthWithGITPAT" variable already exists and the apikey was added at installation

ivan-hc commented 7 months ago

the function above must be placed in the line above each of the two starting with "start=", as you suggested in the first comment

ivan-hc commented 7 months ago

To enable apikey in the AM-updater, with the function above, onty if the user uses apikey

if test -f $AMPATH/ghapikey.txt; then
    if grep -q "github_pat_" $APPSPATH/$2/AM-updater; then
        ghapikey=$(echo "Authorization: token  $(cat $APPSPATH/$2/AM-updater | tr ' ' '\n' | grep "github_pat")")
        if [ "$ghapikey" != "$HeaderAuthWithGITPAT" ]; then
            sed -i "s/$ghapikey/$HeaderAuthWithGITPAT/g" $APPSPATH/$2/AM-updater
        fi
    elif grep -q " https://api.github.com" $APPSPATH/$2/AM-updater; then
        if ! grep -q "github_pat_" $APPSPATH/$2/AM-updater; then
            sed -i "s# https://api.github.com#$HeaderAuthWithGITPAT https://api.github.com#g" $APPSPATH/$2/AM-updater
        fi
    fi
fi

add this function and go refactor the updater.am module.

ivan-hc commented 7 months ago

We can also patch all existing AM-updater files at start. We can put the function above on top of the module:

#!/usr/bin/env bash

for f in $APPSPATH/*/; do 
    cd $f 2>/dev/null && 
    if test -f ./AM-updater; then
        if test -f $AMPATH/ghapikey.txt; then
            if grep -q "github_pat_" ./AM-updater; then
                ghapikey=$(echo "Authorization: token  $(cat $./AM-updater | tr ' ' '\n' | grep "github_pat")")
                if [ "$ghapikey" != "$HeaderAuthWithGITPAT" ]; then
                    sed -i "s/$ghapikey/$HeaderAuthWithGITPAT/g" ./AM-updater
                fi
            elif grep -q " https://api.github.com" ./AM-updater; then
                if ! grep -q "github_pat_" ./AM-updater; then
                    sed -i "s# https://api.github.com#$HeaderAuthWithGITPAT https://api.github.com#g" ./AM-updater
                fi
            fi
        fi
    fi
done

while [ -n "$1" ]; do
...
ivan-hc commented 7 months ago

Or better, in case the user does not want to use apikey anymore

#!/usr/bin/env bash

for f in $APPSPATH/*/; do 
    cd $f 2>/dev/null && 
    if test -f ./AM-updater; then
        if grep -q " https://api.github.com" ./AM-updater; then
            if grep -q "github_pat_" ./AM-updater; then
                apikey=$(cat $./AM-updater | tr ' ' '\n' | grep "github_pat_")
                ghapikey=" --header \"Authorization: token $apikey\" "
                if test -f $AMPATH/ghapikey.txt; then
                    if [ "$ghapikey" != "$HeaderAuthWithGITPAT" ]; then
                        sed -i "s#$ghapikey#$HeaderAuthWithGITPAT#g" ./AM-updater
                    elif ! grep -q "github_pat_" ./AM-updater; then
                        sed -i "s# https://api.github.com#$HeaderAuthWithGITPAT https://api.github.com#g" ./AM-updater
                    fi
                else
                    sed -i "s# $ghapikey # #g" ./AM-updater
                fi
            fi
        fi
    fi
done

while [ -n "$1" ]; do
...
ivan-hc commented 7 months ago

The function above is something you should test on your own, also because I don't use apikey (and I get bored of generating a new one every 2-3)

ivan-hc commented 7 months ago

@nazdridoy Let simplify our life and let set $apikey and $ghapikey as variables only for the key, not the whole option for wget:

#!/usr/bin/env bash

for f in "$APPSPATH"/*/; do 
    cd "$f" 2>/dev/null && 
    if test -f ./AM-updater; then
        if grep -q " https://api.github.com" ./AM-updater; then
            if grep -q "github_pat_" ./AM-updater; then
                apikey=$(cat ./AM-updater | tr ' ' '\n' | grep "github_pat_")
                if test -f "$AMPATH"/ghapikey.txt; then
                    ghapikey=$(cat "$AMPATH"/ghapikey.txt)
                    if [ "$apikey" != "$ghapikey" ]; then
                        sed -i "s#$apikey#$ghapikey#g" ./AM-updater
                    elif ! grep -q "github_pat_" ./AM-updater; then
                        sed -i "s# https://api.github.com#$HeaderAuthWithGITPAT https://api.github.com#g" ./AM-updater
                    fi
                else
                    sed -i 's# --header "Authorization: token '"$apikey"'" # #g' ./AM-updater
                fi
            fi
        fi
    fi
done

while [ -n "$1" ]; do
...
ivan-hc commented 7 months ago

We can also check if the apikey stored is good or just sh*t

#!/usr/bin/env bash

for f in "$APPSPATH"/*/; do 
    cd "$f" 2>/dev/null && 
    if test -f ./AM-updater; then
        if grep -q " https://api.github.com" ./AM-updater; then
            if grep -q "github_pat_" ./AM-updater; then
                apikey=$(cat ./AM-updater | tr ' ' '\n' | grep "github_pat_")
                if test -f "$AMPATH"/ghapikey.txt; then
                    ghapikey=$(cat "$AMPATH"/ghapikey.txt)
                    if [[ "$ghapikey" =~ ^(gh[ps]_[a-zA-Z0-9]{36}|github_pat_[a-zA-Z0-9]{22}_[a-zA-Z0-9]{59})$ ]]; then
                        if [ "$apikey" != "$ghapikey" ]; then
                            sed -i "s#$apikey#$ghapikey#g" ./AM-updater
                        elif ! grep -q "github_pat_" ./AM-updater; then
                            sed -i "s# https://api.github.com#$HeaderAuthWithGITPAT https://api.github.com#g" ./AM-updater
                        fi
                    fi
                else
                    sed -i 's# --header "Authorization: token '"$apikey"'" # #g' ./AM-updater
                fi
            fi
        fi
    fi
done

EDIT: if I have to continue inserting functions in "if" and extending the size of the file I risk going overboard, in which case you have to wait another 6 months, because that's the waiting time in Italy to get a passport issued.

ivan-hc commented 7 months ago

The draft is here https://github.com/ivan-hc/AM/blob/dev/modules/update.am

I've an issue in replacing the old key with the new one, at line 14 https://github.com/ivan-hc/AM/blob/531d2d1e08924f5f806cde721f724ca1d1d0bc57/modules/update.am#L14

PS: the CONTRIBUTING.md file will come with the PR, when the module is ready and then this issue fixed

nazdridoy commented 7 months ago

196 should fix this issue.